[00:01.760 --> 00:05.900]  Greetings, everybody. Good morning, good afternoon, good evening,
[00:05.900 --> 00:11.000]  based on wherever you are. Welcome to my talk on modern Red Team Tradecraft.
[00:11.380 --> 00:19.580]  I'd like to start off by thanking you all for viewing my talk and also a huge thank you to the
[00:19.580 --> 00:26.160]  brilliant team behind DEF CON Red Team Village for putting together over 200 hours of content
[00:26.160 --> 00:30.840]  on Red Teaming. So, massive props to Omar and the team.
[00:32.220 --> 00:38.460]  All right. Quick introduction. I'm a senior consultant at Mandiant. My job involves
[00:38.460 --> 00:45.340]  simulating an adversary, otherwise known as Red Teaming or Purple Teaming. I also keep a keen eye
[00:45.340 --> 00:52.400]  out on tradecraft and the tactics, techniques, and procedures used by the most sophisticated
[00:52.400 --> 00:59.820]  threat actors out there. I'm a first-time DEF CON speaker. So, yay. And you can reach out to
[00:59.820 --> 01:07.600]  me on Twitter at Sajal underscore Thomas. Most importantly, the opinions in this talk are mine
[01:07.600 --> 01:19.290]  and not my employer's. Quick disclaimer here. Right. So, the agenda for today is going to be
[01:19.390 --> 01:26.550]  a range of topics. We're going to cover why help offense to begin with. And then we'll spend some
[01:26.550 --> 01:33.470]  time on talking about implant design considerations and OPSEC decisions that a Red Team operator
[01:34.410 --> 01:42.830]  would require to make in order to sufficiently simulate a sophisticated adversary. We'll talk
[01:42.830 --> 01:51.510]  about how offense informs defense. And there's also a short section on credential harvesting
[01:51.510 --> 01:58.450]  because, naturally, no Red Team talk is complete without a topic on credential harvesting.
[01:58.890 --> 02:07.050]  Lastly, we'll cover how someone can get into Red Teaming and also how the modern Red Teamer
[02:07.050 --> 02:16.550]  needs to evolve and scale up in order to adequately simulate some of the sophisticated
[02:16.550 --> 02:21.570]  adversaries out there. At the end, we'll open up the floor for questions on the Discord server.
[02:21.570 --> 02:27.310]  So, please feel free to leave questions during the course of the talk as well as right at the end.
[02:29.150 --> 02:34.450]  All right. So, the big question is why help offense in the first place? Why spend time
[02:34.940 --> 02:42.070]  and energy in improving a team that merely serves the purpose of keeping you on your toes?
[02:42.490 --> 02:49.070]  So, before we get into that, let's quickly rewind the clock to the peak of the Cold War era
[02:49.720 --> 02:55.220]  to draw some inspiration from clandestine intelligence and counterintelligence operations.
[02:57.460 --> 03:06.500]  So, what you're looking at is the glorious A-12 reconnaissance plane. This was built by Lockheed
[03:06.500 --> 03:14.680]  back in the 60s. And the purpose of this plane was to collect intelligence on the ground
[03:14.680 --> 03:21.760]  by flying through certain sensitive areas. And the main objective of this plane was reconnaissance
[03:21.760 --> 03:31.360]  and surveillance. And this plane was also known as the Archangel. And also, in declassified
[03:31.360 --> 03:38.100]  documents, it was called the Oxcart plane. And thanks to all the declassified documents,
[03:38.100 --> 03:44.700]  we now know a lot more about this plane and about how the United States had to keep it hidden
[03:45.130 --> 03:55.620]  from the Soviets' spying eyes. So, the Area 51 personnel that was operating on this plane,
[03:55.620 --> 04:03.320]  and Area 51 was the hangar where the plane was being developed and tested. The personnel there
[04:03.320 --> 04:10.140]  soon realized that they would need to keep the plane hidden from Soviet spy satellites,
[04:10.140 --> 04:18.300]  who in return would be capturing images of the plane from up above. So, in order to hide it,
[04:18.300 --> 04:25.520]  they would quickly scoot it into a building as soon as they would learn that a spy satellite was
[04:26.380 --> 04:37.420]  about to enter into the Area 51 airspace. And T.D. Barnes, a former hypersonic flight specialist,
[04:37.420 --> 04:43.140]  used to say that if a plane happened to be out in the open when the satellite was coming over
[04:43.140 --> 04:51.660]  the horizon, they would quickly scoot it into a building. And he would say that the entire hangar
[04:51.660 --> 04:57.220]  would look like a parking lot. He said that it would look like, after all the cars have left,
[04:57.220 --> 05:03.160]  you can still see how many were parked there in infrared because of the difference in the
[05:03.160 --> 05:14.760]  ground temperatures. So, as you can see, all the A-12 planes parked in the hangar with the shadows
[05:14.760 --> 05:20.760]  that they left behind on the ground. So, the difference in the temperatures and the heat
[05:20.760 --> 05:26.800]  signatures on the ground where they were parked were naturally much different to the heat signatures
[05:26.800 --> 05:34.840]  of the entire hangar. And so, it turned out that even with all the laborious hooting and scooting
[05:34.840 --> 05:41.880]  of the planes in and out of buildings, the US spies learned that the Soviets had managed to
[05:42.340 --> 05:49.000]  get their hands on a drawing of the A-12 plane. And they assumed that they got it via the infrared
[05:49.000 --> 05:57.500]  satellites. So, in order to thwart these infrared satellites, the Area 51 crew began constructing
[05:58.040 --> 06:04.560]  fake planes out of cardboard and other mundane materials in order to cast misleading shadows
[06:05.080 --> 06:14.860]  for Soviet spy satellites to keep wandering over. And we also know now that sometimes the hangar
[06:14.860 --> 06:21.920]  staff would fire up heaters near these imaginary engine locations to make it appear as if the
[06:21.920 --> 06:31.880]  planes had just landed. And so, as red teamers and as professionals who are trying to simulate
[06:32.560 --> 06:38.200]  an Apex adversary, what are the lessons here for us? The lessons here are that
[06:39.160 --> 06:47.440]  every Apex adversary knows which action leaves what trace behind. And by knowing this, by knowing
[06:47.440 --> 06:54.220]  which signals are exposed to defenders, adversaries can mislead observers in the opposite direction.
[06:54.220 --> 07:02.500]  So, naturally, if you know that your enemy or your observer is monitoring your heat signatures,
[07:02.500 --> 07:10.820]  what you can do is throw them off by planting fake heat signatures and confusing them.
[07:11.580 --> 07:18.300]  So, that was one of the lessons that I gathered from this story. And the other one is that when
[07:18.300 --> 07:25.120]  stealth becomes a necessity, and on the other hand, if it affects the pace of the operation,
[07:25.720 --> 07:32.000]  then what do you do? Do you give up stealth and expose yourself? Or do you continue to remain
[07:32.000 --> 07:38.240]  stealthy but not move in the direction of your objectives? This is a question that
[07:38.240 --> 07:45.600]  every red team operator has faced or will face at some point in every operation.
[07:46.680 --> 07:52.820]  But we can conclude that having a formidable adversary to practice against does keep you
[07:52.820 --> 07:59.880]  on your toes. And knowing every action and every signal that you leave behind
[08:00.320 --> 08:08.340]  does help you understand how you can improve yourself, and by improving yourself,
[08:08.340 --> 08:12.440]  how you can improve the blue team, which is the defense.
[08:14.460 --> 08:24.660]  So, back in 2013, Lockheed Martin announced the SR-72,
[08:25.220 --> 08:33.400]  which and they announced it with this huge slogan saying speed is the new stealth. And
[08:34.360 --> 08:41.660]  they said that the plane goes so fast that it's going to be invisible to radars and it's going
[08:41.660 --> 08:49.580]  to be undetectable in the air. But from a red team operator's point of view, is speed really
[08:49.580 --> 08:59.020]  the new stealth? Now, there's a line of thought among red team operators that going in and getting
[08:59.020 --> 09:07.760]  out very quickly is something that's boastworthy. I, myself, am a victim to this. I have boasted
[09:07.760 --> 09:14.360]  many a times that I got DA on day one and I completed this objective and that objective
[09:14.360 --> 09:26.660]  within a few days and that was it. But truly, does this impact really help the defense achieve
[09:26.660 --> 09:35.320]  their goals? Or does this help the defense to get better themselves? Or does spending a lot more
[09:35.320 --> 09:43.320]  time and remaining undetected demonstrate more impact to the blue team? Now, the defense of tech
[09:44.180 --> 09:51.500]  has set a new precedent. There's a lot of behavioral analysis and baselining
[09:51.500 --> 09:59.600]  what is normal on an endpoint, on a network. And what happens is that anything that
[10:00.920 --> 10:07.920]  goes beyond that normal or anything that comes off as an anomaly immediately generates an alert.
[10:08.800 --> 10:15.980]  And so, allow me to share a war story of mine where I performed a Kerberos attack and I pulled
[10:15.980 --> 10:22.920]  30 service account Kerberos TGS tickets within a few seconds. Because that's the default action
[10:22.920 --> 10:27.520]  when you perform any sort of Kerberos attack straight out of the box. Whether it's via
[10:27.520 --> 10:36.400]  Rubius or whether you use the PowerShell script, PowerView by picking invoke Kerberos. The default
[10:36.400 --> 10:41.520]  is that it will just Kerberos every single service ticket that's in the active directory.
[10:42.520 --> 10:50.720]  So, what happened is that defenders were watching for quantity of requests. And
[10:51.460 --> 10:58.960]  they were watching that quantity in the given time frame that I generated all those service
[10:59.520 --> 11:05.600]  ticket requests. And they picked up this anomaly. And unfortunately, that was the end of my foothold
[11:10.460 --> 11:22.440]  So, this is from the blog by at debugprivilege on Twitter. It's a blog on hunting for tactics,
[11:22.440 --> 11:28.520]  techniques, and procedures using Azure Sentinel. And what debugprivilege talks about is that
[11:30.460 --> 11:37.640]  how requesting a huge number of Kerberos service tickets counts as an OPSEC failure. Because
[11:38.340 --> 11:46.300]  if you were to look at the data from 30 days and establish a baseline of service ticket requests,
[11:46.300 --> 11:52.760]  I'm sorry, Kerberos service account ticket requests, then you can have a very
[11:54.060 --> 12:04.820]  informed idea about how many requests or how many Kerberos tickets are requested per user per day.
[12:04.820 --> 12:09.600]  And then you can set a threshold and anything that goes above that threshold
[12:09.600 --> 12:16.540]  can just be deemed suspicious. So, to conclude, maybe speed is not the new stealth for Red Team
[12:16.540 --> 12:23.760]  operations. And maybe boosting about speed may not be the right approach to demonstrate impact.
[12:27.300 --> 12:32.700]  Okay. So, let's talk about certain Red Team implant design considerations
[12:33.740 --> 12:40.980]  that will help you achieve your objectives and also simulate a sophisticated adversary. Keep
[12:40.980 --> 12:46.260]  in mind that we are going to be talking about Red Team implants alone. We are not going to pick
[12:46.260 --> 12:53.820]  apart any of the implants used by APT actors. Right. So, let's say you want to start from
[12:53.820 --> 12:59.600]  scratch and you do not want to rely on a commercial or open source tool. What are the few
[12:59.600 --> 13:05.340]  considerations you'd want to take into account to achieve this goal? So, typically, this would
[13:05.340 --> 13:12.860]  depend entirely on what kind of adversary you're simulating. If you want to simulate an APT group,
[13:12.860 --> 13:18.900]  then you would want to focus a lot more on stealth, whereas if you were simulating a criminal
[13:18.900 --> 13:25.620]  or a ransomware group, then you'd naturally want to spend a lot more time on speed and
[13:25.620 --> 13:31.300]  you don't spend more time on making your implant
[13:33.780 --> 13:41.780]  able to infect a lot more variety of hosts. So, you would not want to restrict it to only a
[13:41.780 --> 13:49.200]  certain operating system, for example, because you want to deploy it at scale. So, some of the
[13:49.200 --> 13:53.220]  considerations that you would take into account would be to pick a language, to pick a structure
[13:53.220 --> 13:58.980]  of your toolkit, to pick a strategy to execute your post-exploitation capability, because
[13:58.980 --> 14:09.500]  you don't want to have your entire implant with all the post-exploitation capability in it. And
[14:09.500 --> 14:15.760]  we're going to talk about why in the next slide. And for inspiration, the first thing you can do
[14:15.760 --> 14:21.360]  is to look at the release notes of Cobalt Strike, because there's a lot to learn from the evolution
[14:21.360 --> 14:28.960]  of Cobalt Strike's beacon in the past few years. So, my personal recommendation would be to write
[14:28.960 --> 14:35.260]  in C or C++, because this gives you the freedom and flexibility to interact with the native
[14:35.260 --> 14:43.460]  Windows 32 API, also known as Win32 API. And the structure that you would want to implement would
[14:43.460 --> 14:49.600]  be to write modular libraries for each post-exploitation capability. So, each capability
[14:49.600 --> 14:56.500]  should be a separate module. So, if you want to keylog, then your keylogger should be a separate
[14:56.500 --> 15:05.460]  capability. And that capability should be a separate library. So, not only is this easier
[15:05.460 --> 15:10.440]  to maintain and upgrade, but there's an object benefit here, like I was mentioning in the previous
[15:10.440 --> 15:19.300]  slide, that if the keylogging module gets burned, then at least the rest of your modules remain safe.
[15:19.300 --> 15:26.180]  So, you're not just deploying your implant with all the capabilities in it and injecting it into the
[15:26.180 --> 15:32.840]  memory of your victim. What you want to do, ideally, is to have separate modules for all your
[15:32.840 --> 15:42.960]  different capabilities, and then use them as per your need. And you also want to decide
[15:42.960 --> 15:50.500]  how to approach injecting your capabilities. So, there are two major options here. One is
[15:51.320 --> 15:58.860]  the fork and run option, which Cobalt Strike uses as well. So, this approach is essentially
[15:59.680 --> 16:08.180]  creating a sacrificial process and injecting your capability into it, letting it complete,
[16:08.180 --> 16:14.360]  and then closing the process and killing the process. So, that is one option. The other option
[16:14.360 --> 16:21.020]  is to inline execute into your own process. So, the process that you're running under,
[16:21.700 --> 16:27.760]  the process which your implant is running under, you inject your capability into this very same
[16:27.760 --> 16:36.840]  process, and you let the job complete. Now, there are caveats for both. The fork and run is
[16:36.840 --> 16:44.060]  actually a lot less stealthy, and I'll explain why in the next few slides.
[16:44.400 --> 16:52.160]  And the inline execute option is much more stealthy, but it runs the risk of destabilizing
[16:52.160 --> 16:59.640]  your implant process. So, my personal recommendation is that if you have processes,
[16:59.640 --> 17:06.400]  or if you have capabilities that you want to run over a long period of time, then you pick the fork
[17:06.400 --> 17:14.820]  and run option. And if there are smaller capabilities or capabilities that run for a
[17:14.820 --> 17:20.500]  much shorter time frame, then you just inline execute them into your own process.
[17:20.500 --> 17:26.560]  Also, Cobalt Strike has this feature, which is a newly launched feature called
[17:26.560 --> 17:34.100]  the ability to make beacon object files. And I'm not going to get into the details of how that
[17:34.100 --> 17:40.680]  works, but essentially, beacon object files now allow you to inline execute capabilities
[17:40.680 --> 17:49.940]  into your own process instead of the typical fork and run. So, this is a move that promotes stealth,
[17:49.940 --> 18:00.340]  but also, like I mentioned, there are some caveats to that. So, great. So,
[18:00.340 --> 18:05.100]  you're operating in memory, and that's perfect. That's what you want. You don't want to touch
[18:05.100 --> 18:10.740]  disk. All that is great, but that doesn't mean that you will remain undetected. It doesn't mean
[18:10.740 --> 18:18.640]  in memory doesn't mean undetectable. Subty, also known as Casey Smith, once tweeted,
[18:18.640 --> 18:25.680]  and in typical Subty fashion, deleted his tweet about the three pillars of endpoint detection
[18:25.680 --> 18:33.740]  and response, where he said that there are three things that form the pillars of EDR
[18:33.740 --> 18:40.260]  and the three pillars are parent-child process relationships, command line arguments,
[18:40.260 --> 18:47.020]  and network connections made by processes. Now, this makes a lot of sense from an EDR
[18:47.020 --> 18:53.220]  point of view, and from a Red Teamers point of view, if we were to bake these evasions
[18:54.100 --> 19:02.960]  into the implant design, then we can have a sufficiently OPSEC safe and stealthy implant.
[19:02.960 --> 19:11.120]  Now, thanks to Will's talk at Wild West Hacking Fest, we already have the evasions for the first
[19:11.120 --> 19:19.280]  two pillars, and the last one is something we can actually do manually, or we can program that
[19:19.280 --> 19:28.380]  logic into our implant in order to pick processes that are typically known to make network connections
[19:28.380 --> 19:35.620]  and use them if we want to make certain network connections inside the network, or egressing from
[19:35.620 --> 19:46.060]  the network. So, when a process launches, EDR solutions check for anomalies. So, the typical
[19:46.060 --> 19:56.320]  examples include word.exe spawning partial.exe, and then for command line arguments, this is
[19:56.980 --> 20:04.960]  the typical detection for that is looking for suspicious parameters like a partial-execution
[20:04.960 --> 20:18.980]  policy, and proc dump-n lsast.exe, hyphen accept EULA, and the network connections are, of course,
[20:18.980 --> 20:24.880]  fairly straightforward. If you see, if EDR sees explorer.exe making connections to the internet,
[20:24.880 --> 20:30.820]  this is naturally something that's going to come across as suspicious. So,
[20:30.820 --> 20:37.820]  these are some of the ways that EDR performs the very basic detections.
[20:38.300 --> 20:46.520]  Now, let's quickly talk about pair-and-process spoofing. This isn't a new technique. This was
[20:46.520 --> 20:56.640]  blogged by DDR Stevens almost 11 years ago. And, in order to understand how pair-and-process
[20:56.640 --> 21:04.700]  spoofing works, let's first look at the very basics. Let's look at the Win32 API call to
[21:04.700 --> 21:14.140]  create a process. And what this looks like is a function called create process A with certain
[21:14.140 --> 21:19.660]  parameters. And the parameter that we are interested here is
[21:21.720 --> 21:33.990]  the LP startup info A parameter. So, we want to make LP startup info point to an extended startup
[21:33.990 --> 21:42.750]  info struct called startup info XA. The struct startup info XA contains an attribute list called
[21:42.750 --> 21:50.070]  LP attribute list. And the attribute list can be updated using the function update
[21:50.070 --> 21:58.190]  drop thread attribute. So, as you can see, the LP value parameter can specify which process,
[21:58.190 --> 22:05.650]  which pair-and-process you want to choose for the process that you create. So, LP value will be a
[22:05.650 --> 22:10.550]  pointer to the handle to the process which you want to spoof as the parent, as you can see in
[22:10.550 --> 22:22.130]  the image below. And this is proof of concept code from XPN, also known as Adam Chester. You
[22:22.130 --> 22:32.630]  can observe the update drop thread attribute function which takes ampersand P handle as the
[22:32.630 --> 22:43.390]  argument. And that in itself is the handle to an open process call to the specific process ID that
[22:43.390 --> 22:51.250]  we pick. Right. So, the second evasion technique talks about spoofing command line arguments.
[22:52.270 --> 22:59.110]  As I mentioned previously, EDR looks at this quite closely. There are many such examples.
[22:59.110 --> 23:08.990]  I mentioned Procmon, which dumps the LSAS memory. Certain other examples also include
[23:09.830 --> 23:18.070]  WMIC OS get slash format with a web URL pointing to an XSL style sheet, which
[23:18.950 --> 23:27.290]  is also known as squiggly2, which was an attack discovered by Casey Smith a while back. And
[23:28.070 --> 23:37.310]  in order to evade this detection mechanism, what we would do is we would first create a process,
[23:37.310 --> 23:42.730]  suspend its state, change the command line parameters in the memory to something harmless,
[23:42.730 --> 23:52.910]  and then resume the process. But in order to do that, we first need to understand what
[23:52.910 --> 24:00.190]  process environment block is, also known as PEB. Now, a PEB is mapped inside the process's
[24:00.190 --> 24:05.970]  virtual memory. It contains information about the process, such as loaded modules,
[24:05.970 --> 24:12.370]  command line arguments used, and other such information related to the process.
[24:14.270 --> 24:19.970]  And like I mentioned, the few steps involved in this process would be to create a process
[24:19.970 --> 24:28.810]  in the suspended state, and then get the address of the PEB using the NT query information process
[24:28.810 --> 24:37.790]  function call. This is something that tools like Process Hacker also do. And that is how XPN took
[24:37.790 --> 24:45.850]  inspiration in order to do this. And what you do next is you replace the command line
[24:46.770 --> 24:52.070]  arguments stored in the PEB using write process memory, and then you just resume the memory. So,
[24:52.070 --> 24:59.590]  when you see it, when you see the logs, what you'll see is the harmless parameters are logged,
[24:59.590 --> 25:07.790]  and not the ones that you started the process with. So, POC code yet again by Adam Chester.
[25:08.170 --> 25:15.910]  As you can see, the spoof parameters right at the bottom. But you start with reading
[25:16.710 --> 25:24.630]  the PEB from the target process using a reprocess memory call right at the top of the image. And
[25:24.630 --> 25:30.330]  then you get the process parameters from the PEB using reprocess memory yet again,
[25:30.330 --> 25:38.210]  and using the handle to the process. And you replace the suspicious parameters with
[25:39.190 --> 25:44.390]  something harmless using write process memory, and pointing to the PEB.
[25:47.850 --> 25:54.670]  The other interesting feature lets you prevent third-party DLLs from injecting into the
[25:55.130 --> 26:06.170]  process space of your implant. If you will recall, in September 2018, Chrome 69 started this feature
[26:06.170 --> 26:11.390]  where it began blocking third-party software from injecting into the Chrome's process space.
[26:11.390 --> 26:20.110]  They did this to enhance the stability of Chrome. And this feature gave inspiration to Raphael
[26:20.110 --> 26:28.390]  Mudge, creator of CobaltStrike, to bake this into CobaltStrike's payload, which is called Beacon.
[26:28.550 --> 26:33.930]  And for those of you familiar with Beacon, you know that this is something we can achieve by
[26:33.930 --> 26:41.890]  using the block DLLs command. And what block DLLs essentially does under the hood is that
[26:41.890 --> 26:47.670]  it creates a process with an attribute that disallows any third-party DLLs from injecting
[26:47.670 --> 26:57.750]  into the spawn processes. So think fork and run processes of Beacon for its post-exploitation and
[26:58.670 --> 27:04.670]  the block DLLs feature combined with it. So any new process you create in order to inject
[27:04.670 --> 27:12.470]  capability into it, you can also set this feature into it so that it prevents any third-party DLLs
[27:12.470 --> 27:17.970]  from injecting into your sacrificial post-exploitation processes. The caveat here, of
[27:17.970 --> 27:25.310]  course, is that only Microsoft-signed DLLs can inject into these processes. Anything that's not
[27:25.310 --> 27:34.830]  signed by Microsoft cannot. And we can also use arbitrary code guard, which uses a process
[27:34.830 --> 27:45.660]  mitigation policy to achieve similar results. So looking at the code, you'll see the familiar
[27:45.660 --> 27:51.400]  update prop thread attribute function call yet again. What is happening here is that the create
[27:51.400 --> 27:57.980]  process function call is used along with the startup info xa struct, which we talked about
[27:57.980 --> 28:06.580]  earlier. And in this case, this struct contains the mitigation policy which prevents non-Microsoft
[28:06.580 --> 28:17.930]  signed DLLs from being injected. So when you observe this process, you'll see that there's a
[28:17.930 --> 28:27.030]  policy set which will specify signature restricted to Microsoft only.
[28:29.370 --> 28:38.290]  Of course, as everything is sophisticated, the level of sophistication of your activity will
[28:38.290 --> 28:48.410]  give away your intent. If your protected processes are something that are not normal to the environment
[28:48.410 --> 28:53.310]  that you're operating in, then it is going to stick out like a sore thumb. So the best advice
[28:53.310 --> 28:58.850]  here is, of course, to blend in by enumerating the mitigation policies on all the processes that are
[28:58.850 --> 29:08.780]  running, and then act accordingly. So for every APEX adversary, it's very important for you to
[29:08.780 --> 29:15.800]  know your toolkit. And as red teaming advances and becomes more mature, this becomes more and
[29:15.800 --> 29:22.170]  more important. Because knowing what your toolkit does under the hood is absolutely essential.
[29:23.800 --> 29:29.930]  Now, going back to the initial point, every action by an attacker leaves a trace behind.
[29:30.540 --> 29:35.560]  For an attacker to reach a certain level of sophistication, it is crucial to understand
[29:36.410 --> 29:43.460]  each action and its detection risk. This often means, for a red team operator,
[29:43.460 --> 29:52.360]  the fewer processes you create, the stealthier this would be. The image on the right is actually
[29:52.560 --> 29:58.500]  a screenshot of Raphael Mudge's excellent nine-part video series on red team operations.
[29:59.020 --> 30:06.860]  I'm going to touch upon that in the very last section of this talk. But what you see here is
[30:07.510 --> 30:15.600]  every action and every detection risk that is tied to it from a Sysmon perspective. So
[30:16.550 --> 30:26.160]  you can see red is naturally more expensive. And by expensive, we mean risky. And the ones
[30:26.160 --> 30:31.680]  that stick out here are the create remote thread calls, the process create calls, and
[30:32.400 --> 30:37.100]  process access. So process access includes everything from injection
[30:39.060 --> 30:46.900]  to hash dump to running mimikatz. And all the green ones are the relatively safer actions. So
[30:48.200 --> 30:52.660]  file create is a very safe option. It's not something that's going to
[30:53.600 --> 30:58.600]  ring alarm bells all over, because this is something that happens on every endpoint,
[30:58.600 --> 31:05.860]  and you can't possibly have alerts set for that, because you'd have a huge ton of false positives.
[31:06.580 --> 31:15.540]  Process termination is also safe. Time stomping is surprisingly a safe activity.
[31:19.420 --> 31:24.300]  Right. So at every stage of a red team operation, you will be required to make an informed decision
[31:24.300 --> 31:32.160]  about whether your action is going to generate an alert or also get blocked. And based on that,
[31:32.160 --> 31:37.910]  you will then decide how you want to proceed with achieving your objectives.
[31:44.860 --> 31:53.500]  So the caveat here is that actions that are loud aren't necessarily always blocked or caught
[31:53.500 --> 31:59.680]  straight off the bat. And Raphael sums this up very well when he says that observable does not
[31:59.680 --> 32:07.320]  mean observed. So the strategy is to blend in with the legitimate host and network activity.
[32:07.880 --> 32:15.220]  This is something that Raphael terms as session prepping. And what he means by that is
[32:15.960 --> 32:22.100]  that you observe the endpoint and its behavior and merge with it.
[32:22.340 --> 32:28.840]  My personal recommendation is that you may have to change up your session prepping based on the
[32:28.840 --> 32:33.840]  kind of activity you want to perform or the kind of post-exploitation capability that you want to
[32:33.840 --> 32:42.760]  perform. And to give you an example, for something like network reconnaissance,
[32:42.760 --> 32:48.400]  you will want to appear as a process that frequently makes a lot of network connections
[32:48.400 --> 32:56.420]  internally. So here what I would do is I would try to observe every single process that's
[32:56.420 --> 33:01.040]  making internal network connections and try to masquerade as one of them.
[33:02.360 --> 33:08.280]  And also bypassing the three pillars of EDR will only help your initial foothold,
[33:08.280 --> 33:15.060]  they'll only get you so far. What you do after that, whether you stay hidden, is entirely
[33:15.060 --> 33:22.600]  on the operator. Disabling logging instrumentation is also something that's gaining
[33:23.480 --> 33:30.660]  a fair amount of popularity these days. It's not something that a third party red team
[33:30.660 --> 33:36.620]  typically does. Why is that? It's because you're testing your customer's blue team at the end of
[33:36.620 --> 33:45.200]  the day. And if they agree to disabling login, then naturally we have a few
[33:45.200 --> 33:52.460]  options in terms of some of the new ETW bypasses that have come to light and some of the Sysmon
[33:52.460 --> 33:59.640]  evasions and unloading of Sysmon that have been blogged about in the past few years.
[33:59.820 --> 34:05.680]  So these are some of the options we have. But again, this is not something we typically do on
[34:05.680 --> 34:15.280]  red team engagements. So coming back to the point about blending in, your first step should always
[34:15.280 --> 34:21.140]  be to enumerate the running processes and their parent-child relationships. Once you have a decent
[34:21.140 --> 34:28.080]  idea of what's running, you pick a parent and a child relationship of a process that you want
[34:28.080 --> 34:35.400]  to masquerade as, and you configure it on your implant. So this is something that you should
[34:35.400 --> 34:41.200]  have the option to do on the fly and not something that you have to hard code and just stick with for
[34:41.200 --> 34:48.400]  the rest of the engagement. Because like I said, this is something that you may want to change
[34:48.400 --> 34:55.500]  based on the activity that you perform. Some common examples that you will see on the endpoints will
[34:55.500 --> 35:04.200]  be a browser parent process. Now, Internet Explorer used to have it with one parent process
[35:04.840 --> 35:11.460]  called iExplore.exe, and then all the tabs that you subsequently open would also show up as child
[35:11.460 --> 35:18.720]  processes of that one parent process, iExplore.exe. There are other such examples. One of them is
[35:18.720 --> 35:28.280]  jusced.exe and juscheck.exe. These are the the Java updater parent-child processes,
[35:28.840 --> 35:37.260]  and both of these are good options in order to blend in because they typically make network
[35:37.260 --> 35:46.470]  connections to the internet. So like I was mentioning, Internet Explorer running on an
[35:46.470 --> 35:50.030]  endpoint would look something like this, where there's one parent process and then
[35:50.530 --> 35:56.790]  the tabs that are opened show up as child processes of iExplore.exe.
[35:59.990 --> 36:06.550]  Another quick note about Ruby is, when you're performing Kerberost... I'm sorry, not a note
[36:06.550 --> 36:13.030]  about Ruby, but about Kerberosting in general, this is something that I'm going to bring up
[36:13.030 --> 36:20.050]  once again when we talk about how offense informs defense, because it's, like I mentioned, it's
[36:20.050 --> 36:28.550]  something that very often tends to give us a lot of success in terms of domain privilege escalation.
[36:28.550 --> 36:36.390]  So a quick note about that, I would recommend not pulling all the tickets at once. As you know,
[36:36.390 --> 36:45.030]  I learned this the hard way because I pulled all the service tickets at once and that led to a
[36:45.030 --> 36:53.650]  detection and an alert and an incident and subsequently my foothold was isolated. So an
[36:53.650 --> 36:58.150]  effective strategy here would be to find the service account set with the earliest password set
[36:59.730 --> 37:04.670]  so naturally these service accounts have the password last set attribute on their domain
[37:04.670 --> 37:12.770]  object and that is something you can query. And the great thing about Ruby is that you can now
[37:12.770 --> 37:24.030]  do that with a flag called stats. So you just need to do rubyist.exe Kerberost slash stats and
[37:24.570 --> 37:33.390]  it will give you the encryption types as well as the password last set year along with the number
[37:33.390 --> 37:40.970]  of service accounts that had its password last set in that year. And then once you get this
[37:40.970 --> 37:46.790]  information what I would do is that I would then start pulling tickets from the oldest to newest
[37:47.450 --> 37:55.670]  and if the oldest cracks then brilliant. If it doesn't then I move on to the more recent one and
[37:55.670 --> 38:08.350]  then consequently progress to the more latest password last set dates. So as I mentioned
[38:08.350 --> 38:12.290]  previously when performing internal network reconnaissance you would want to appear as a
[38:12.290 --> 38:18.530]  process that frequently makes internal network connections. A good trick here is to replicate
[38:18.530 --> 38:26.250]  the client's host as a VM as closely as possible and then test all your actions and observe
[38:26.250 --> 38:33.110]  activity from a blue team's perspective. And you can use Sysmon for this all day because it's free
[38:33.110 --> 38:44.850]  and you can also use Swift on security's Sysmon config that's available publicly on the GitHub
[38:44.850 --> 38:52.250]  repository. And by doing so you can then look at the process relationships, the command line
[38:52.250 --> 38:58.730]  arguments and the network connections that your implant is making and how it's appearing on the
[38:58.730 --> 39:08.850]  endpoint. You'd also go a long way if you get familiar with some common quote-unquote normal
[39:08.850 --> 39:16.590]  Windows parent-child process relationships. And Sameer on Twitter posted this very informative
[39:16.590 --> 39:24.230]  chart with all of these examples which I refer to very often when I want to masquerade as something
[39:24.230 --> 39:36.290]  legitimate and I strongly recommend that you refer to this chart. All right so offense informs
[39:36.290 --> 39:42.390]  defense and that is why we want to get better at offense and we want to go from the observable
[39:42.970 --> 39:50.950]  to the observed. And we want to help the blue team to observe our activity so that they can defend
[39:50.950 --> 39:58.230]  against threats better. So to detect parent process ID spoofing you would want to start
[39:58.230 --> 40:03.850]  collecting data from event tracing for Windows. Now event tracing for Windows was actually designed
[40:03.850 --> 40:10.130]  for debugging and not for security monitoring but that being said it is gaining popularity to
[40:10.130 --> 40:16.930]  gather granular information about activity performed in the host. So to detect parent
[40:16.930 --> 40:23.370]  process ID spoofing you'd want to collect the event header process ID via ETW and correlate
[40:23.370 --> 40:31.830]  with what parent process ID you're seeing of the process. Also parent process ID spoofing
[40:31.830 --> 40:35.550]  requires creating processes with the extended startup information
[40:37.670 --> 40:43.510]  and you'd want to monitor your process creation calls which have such information. This point is
[40:43.510 --> 40:50.810]  referring to the startup info xa struct and that is a necessity if you want to perform
[40:50.810 --> 40:56.670]  peep and spoofing because only with that struct can you provide the handle
[40:56.670 --> 41:04.690]  of the process that you want to spoof as your parent. And naturally you'd want to watch out
[41:04.690 --> 41:09.630]  for false positives because parent process ID spoofing is actually something that UAC
[41:11.230 --> 41:16.650]  does and this is legitimate behavior. So you're bound to have a few false positives
[41:16.650 --> 41:20.950]  but as long as you know what you're looking for you should be good to go.
[41:22.390 --> 41:31.270]  A quick image posted by the good people at F-Secure, this shows the
[41:32.390 --> 41:40.770]  you can see the event generated by ETW and quite obviously the event header process ID
[41:40.770 --> 41:48.490]  and the parent process ID are different and the event header process ID shows
[41:48.940 --> 41:55.180]  the actual parent which is 9224, process ID 9224.
[41:57.200 --> 42:06.190]  I also want to talk about a concept that Jared Atkinson of SpectreOps talked about in his blog.
[42:07.440 --> 42:15.910]  He said that we have this funnel of fidelity when it comes to detection and blue teaming. The idea
[42:15.910 --> 42:25.710]  here is that the funnel at each stage exists to filter out noise in a calculated way but also
[42:25.710 --> 42:33.030]  affects the ability of a future step to be successful. So as you can see you may have
[42:33.370 --> 42:42.470]  a million events in your detection funnel but with all the filters you have in place, be it
[42:43.750 --> 42:50.730]  filters of technology or a human eye, everything you have in place should
[42:52.370 --> 42:59.450]  provide output to the very next filter which would take that output as its input. So when
[42:59.450 --> 43:06.070]  you're triaging you should have a lot fewer alerts that you want to send to the next phase.
[43:06.540 --> 43:17.450]  This is because investigating 100 alerts or even 100,000 events is fairly infeasible,
[43:17.450 --> 43:26.490]  no matter how large the organization is. And as Sapti puts it in his talk along with Ross Wolf
[43:27.270 --> 43:34.750]  called Fantastic Red Teams and How to Find Them, he says that behaviors happen over time and we
[43:34.750 --> 43:43.090]  need to monitor where the action happens. So, for example, svchost.exe being spawned without
[43:43.090 --> 43:53.690]  the hyphen k command line parameter is something that's quite obviously suspicious. And svchost.exe
[43:53.690 --> 44:00.730]  being spawned not as a child of services.exe is also something that you should be looking at
[44:01.660 --> 44:09.790]  because the normal process relationship of svchost is as a child of services.exe and again
[44:09.790 --> 44:16.330]  with the command line parameters have hyphen k and the name of the service after that.
[44:16.430 --> 44:24.190]  So another such odd behavior would be system level processes being spawned by non-system
[44:24.190 --> 44:31.030]  parents. This usually indicates some level of local privilege escalation wherein your
[44:32.490 --> 44:40.630]  non-system parent process is generating a system level escalated privilege process.
[44:41.050 --> 44:48.710]  So the idea would be to locate attempts to blend in and also locate legitimate binaries being
[44:48.710 --> 44:57.650]  renamed or being replaced and put in a different directory which is not its standard directory.
[44:58.370 --> 45:05.530]  You would also go a long way if you find processes which are creating network connections
[45:06.530 --> 45:11.030]  but these processes are part of the living off the land binaries, so
[45:11.910 --> 45:21.090]  lolbins as you call it. Another great blog post by Gerald revolves around his philosophy of
[45:21.090 --> 45:27.470]  detecting attacker capabilities. He calls this the concept of capability abstraction.
[45:27.930 --> 45:34.430]  So the idea here is that an attacker's tools are merely an abstraction of their attack
[45:34.430 --> 45:40.270]  capabilities and detection engineers must understand how to evaluate abstraction while
[45:40.270 --> 45:49.850]  building detection logic. So what he means is that when an attacker runs, let's say,
[45:49.850 --> 45:59.950]  Invoke Kerberost or Rubius or Mimikatz, then these present itself as detection opportunities
[45:59.950 --> 46:04.790]  at many levels. So first is the managed code itself
[46:06.650 --> 46:17.250]  and the other is the underlying Win32 API call that is being used and it could also be the RPC
[46:17.250 --> 46:24.530]  call on the network that you could build your detection off of. And lastly, of course, the
[46:24.530 --> 46:35.600]  network protocol that you can monitor for suspicious activity. So speaking of Mimikatz,
[46:36.720 --> 46:44.340]  let's jump to credential harvesting very quickly. So creds are king, naturally. Every red teamer
[46:44.340 --> 46:49.360]  knows this. Credentials are a red teamer's best friend and when we have tame text passwords,
[46:49.360 --> 46:58.720]  it opens up multiple doors for us. Without plain text creds, we have other options like hashes and
[46:58.720 --> 47:07.760]  tickets. But I mean, there's nothing quite like good old text passwords, right? Every red teamer
[47:07.760 --> 47:17.400]  needs to use some sort of credential harvesting tooling in their red team operations. This is
[47:17.400 --> 47:26.000]  because in order to achieve our objectives, we do need to steal credentials and make our way
[47:26.000 --> 47:31.540]  to some level of escalated privileges to complete our objectives.
[47:31.960 --> 47:40.660]  Now, modern defenses have caught on to this trend and made life harder for real world attackers and
[47:40.660 --> 47:46.640]  consequently red teamers. But overall, of course, this is a good thing. We want this to be hard
[47:46.640 --> 47:54.980]  because we don't want it to be easy for the real world bad guys. So certain techniques that
[47:55.660 --> 48:02.760]  have been used are extensive signatures itself for the credential harvesting tools.
[48:03.160 --> 48:11.240]  So we now know that Defender does very, very well against Mimikatz. And by Mimikatz, I mean just the
[48:11.240 --> 48:18.880]  word Mimikatz. You can have the word Mimikatz in a harmless program and it would still be
[48:18.880 --> 48:27.060]  detected as malicious, which I have no complaints against. It is a good thing because nothing
[48:27.060 --> 48:33.220]  legitimate comes out of anything called Mimikatz. But this is a strategy that they've chosen to go
[48:33.220 --> 48:39.640]  with and I respect that. So a few other techniques that we have seen being used are
[48:40.080 --> 48:46.640]  user-learned API hooking. So specific APIs like read process memory
[48:48.400 --> 48:57.700]  and sometimes open process on the LSAS process itself have proven to be
[48:58.640 --> 49:07.980]  suspicious or detectable by certain EDR vendors. And of course, there is protected processes light,
[49:07.980 --> 49:13.920]  which is an OS level mitigation. Alex Ionescu has a great blog post series on
[49:14.540 --> 49:21.120]  PPL if you're interested to get into the details and internals. So what is API hooking?
[49:21.860 --> 49:30.740]  Think of it as a man-in-the-middle attack by the EDR product. As you can see in the image,
[49:30.740 --> 49:37.380]  main.exe is using the create remote thread API call, but this API call is hooked. So
[49:37.380 --> 49:43.100]  what actually happens under the hood is that there's a jump instruction that hijacks the
[49:43.100 --> 49:51.920]  execution flow. And this jump instruction takes the flow of execution to the process space of the
[49:51.920 --> 50:03.360]  EDR and its DLL. So once it's in the process space of that DLL, it will then perform its checks.
[50:03.360 --> 50:08.500]  It will look at the function call. It will look at the arguments. It will see if the parameters
[50:08.500 --> 50:18.420]  are safe. If it's fine, then it decides that execution can resume. If it deems it as suspicious,
[50:18.420 --> 50:28.070]  it will either generate an alert or outright block it. Certain other techniques that have been
[50:28.070 --> 50:38.560]  publicly documented are unhooking these useland API hooks using direct syscalls to ntdll.dll.
[50:40.640 --> 50:46.130]  So what we want to do here is that we want to use the very same hooked API calls,
[50:46.130 --> 50:53.450]  but we want to use the underlying ntdll function call with the help of syscalls in ASN.
[50:53.650 --> 50:59.390]  So in order to do this, you first need to resolve the syscalls from ntdll and then jump directly to
[50:59.390 --> 51:11.220]  the ntdll call. Another alternative that is publicly documented is getting creative with
[51:11.220 --> 51:22.280]  Win32 APIs. For example, the PSS capture snapshot API. This function takes the snapshot of the process
[51:23.300 --> 51:31.500]  and what happens is you can then use the mini dump write dump function on the snapshot of Lsas
[51:31.500 --> 51:39.800]  instead of Lsas itself. So you're essentially creating a copy and performing all your malicious
[51:39.800 --> 51:46.740]  activity on the copy and not the original. So this tends to evade certain detections that rely on
[51:46.740 --> 51:54.420]  your getting a handle on Lsas and reading the process memory of Lsas itself.
[51:57.390 --> 52:04.510]  So in some occasions, you'll also see Lsas running as PPL. This is something that you can
[52:05.330 --> 52:08.310]  observe from the registry key.
[52:10.030 --> 52:14.590]  And this registry key is run as PPL, as you can see in the image.
[52:16.170 --> 52:24.950]  With run as PPL enabled, your options will be limited to dropping a vulnerable,
[52:24.950 --> 52:31.250]  preferably signed kernel driver. And this vulnerable kernel driver will allow you to
[52:31.250 --> 52:37.810]  execute code in kernel space. And this in turn will allow you to load another kernel driver of
[52:37.810 --> 52:47.890]  your choosing. So something like mimi-drv.sys, which is the kernel driver which is created by the
[52:48.610 --> 52:55.030]  creator of Mimikatz. And if the vulnerable driver is unsigned, then you would need to use the
[52:55.030 --> 53:03.710]  driver to first disable driver signing enforcement, then load your driver, and then dump credentials.
[53:04.210 --> 53:09.630]  There's a lot more to this talk, but it's outside this... there's a lot more to this topic,
[53:09.630 --> 53:16.270]  I'm sorry. But it's outside the scope of this talk. And the time frame of this talk.
[53:16.830 --> 53:24.830]  But typically, loading drivers on production environments is deemed risky. And if you want
[53:24.830 --> 53:31.350]  to do this, then you should request permission beforehand. Because ultimately, we are a red team.
[53:31.350 --> 53:38.770]  We are not the real adversary. We don't want to cause blue screens of death on production
[53:38.770 --> 53:48.670]  environments. And as an attacker, of course, the concept of offense in depth is important to us.
[53:48.670 --> 53:55.450]  Because we need to know different techniques to achieve the same goals. Because if one technique
[53:55.450 --> 54:01.890]  does not work, or if one technique has been patched, then you should have the knowledge of
[54:03.110 --> 54:09.960]  different ways to achieve the same result. Which finally brings us to
[54:11.480 --> 54:16.520]  being a red teamer in 2020 and how this has changed in the past few years.
[54:19.410 --> 54:24.510]  So, to begin with, the training landscape for red teaming is ever changing. There are
[54:24.510 --> 54:32.170]  very few courses out there. There are a few good ones, of course. And that number is slowly growing.
[54:32.770 --> 54:41.470]  But most of the mainstream courses have little or no focus on skills that will enable you to walk
[54:41.470 --> 54:51.450]  into a red team role. And like pen test roles as well, there's the catch 22 of red team roles
[54:51.450 --> 54:57.510]  requiring experience and you needing a job in order to get experience in the first place.
[54:58.190 --> 55:04.330]  So, what is the best advice I would give to myself if I had to do it all over again?
[55:04.330 --> 55:11.770]  Well, I would very, very strongly recommend watching Rafael Maggio's Red Team Operations
[55:11.770 --> 55:18.270]  video series. I mentioned earlier that this is a nine-part video series. It's based on
[55:18.270 --> 55:24.390]  Cobalt Strike, but it will teach you the fundamentals of red team tradecraft. And
[55:24.970 --> 55:30.870]  most red team roles will require you to fully understand the ins and outs of Cobalt Strike
[55:30.870 --> 55:40.330]  anyway, so it's a win-win. The best part is that it's free. And there are two such series that I
[55:40.330 --> 55:45.830]  strongly recommend. One is the Red Team Operations, as I mentioned, and the other is the In-Memory
[55:45.830 --> 55:54.970]  Evasion video series, which talks about some of the features that Beacon has recently implemented,
[55:54.970 --> 56:04.030]  which help with keeping it OPSEC safe in memory. So, once you're familiar with a mature C2 framework,
[56:04.330 --> 56:09.410]  I would recommend that you build your own from scratch. A very basic one. It doesn't have to be
[56:09.410 --> 56:14.910]  something sophisticated, but building one yourself will go a long way in helping you understand
[56:15.750 --> 56:24.730]  the nitty-gritties of implants and C2 frameworks. And Rastamouse has a
[56:24.730 --> 56:31.590]  very informative video series on the development of Sharp C2 that is currently
[56:31.590 --> 56:39.610]  ongoing, and I've seen that Rastamouse is very regularly posting videos to this playlist.
[56:41.610 --> 56:48.890]  I would also strongly recommend reading through Dominic Chell's post on learnings from a decade
[56:48.890 --> 56:55.950]  of Red Teaming. He talks about what he has learned in an entire decade of Red Teaming, and there's
[56:55.950 --> 57:03.990]  some very useful insight for someone who's been around for over a decade. And definitely give that
[57:03.990 --> 57:11.570]  one a read. Also, watch Will Burge's talk on Red Teaming. Sorry, Will, if I butchered your last
[57:11.570 --> 57:21.190]  name. This is a very informative talk. It pushed the envelope in favor of Red Teams very, very
[57:21.190 --> 57:30.650]  significantly, and the three pillars of EDR that I kept mentioning throughout the talk are something
[57:30.650 --> 57:39.150]  that Will's talk has also addressed. Also, you would want to master every attack vector on the
[57:39.150 --> 57:47.710]  Active Directory. So, for that, there's no better place than going to Harmjoy's blogs and tweets,
[57:47.710 --> 57:56.590]  and also biotech's tweets, and adsecurity.org, which is a fantastic resource for all things AD
[57:56.590 --> 58:05.980]  and security. Learn about process injection. You can typically do this for free, because there are
[58:05.980 --> 58:12.880]  plenty of resources out there, but I have been made aware of a course by Pentester Academy,
[58:13.240 --> 58:23.840]  and it's being taught by Pavel Yosefovich himself, which is going to be a very promising course,
[58:24.480 --> 58:31.460]  that's something that I might look at taking up as well. I also want to mention that I'm not
[58:31.460 --> 58:39.660]  paid to sponsor any of these trainings, or any of these materials. This is an independent and
[58:39.660 --> 58:48.440]  unbiased recommendation. And lastly, learn how to set up your C2 infra, then automate it for speed
[58:48.440 --> 58:54.410]  and efficiency. You can use Terraform, Ansible, there are plenty of ways. There's a lot of
[58:56.100 --> 59:04.020]  DevOps influence on recent C2 infra deployment, and a lot of people have found very innovative
[59:04.020 --> 59:09.170]  ways to do this. So, keep an eye out, keep reading, never stop learning.
[59:12.600 --> 59:17.740]  So, a huge shout out to the people who make their research public, and push the envelope
[59:17.740 --> 59:27.020]  to improve security. This is a short list, and I'm quite confident that there are a lot more
[59:27.020 --> 59:35.580]  out there who have contributed. And thank you all for all your work, and image credits of the
[59:35.580 --> 59:45.000]  A12 Archangel and SR71 to the good people at Langley. Right. So, now I'll open the floor
[59:45.000 --> 59:51.980]  for questions. Please post all your questions on the Discord server. Thank you all once again
[59:51.980 --> 59:58.900]  for watching my talk. Feel free to reach out to me on Twitter, and have a nice day.
